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EASTHOM, Administrative Patent Judge. 

DECISION ON APPEAL 



STATEMENT OF THE CASE 
Appellant appeals 1 under 35 U.S.C. § 134 from the Examiner's final 
rejection of claims 1-4, 6, 8, 9, 11, 13-16, 18, 20-23, 25, 27, 28, 30, 32-35, 
and 37. The Examiner objected to claims 5, 7, 10, 12, 17, 19, 24, 26, 29, 31, 



1 Reference is to Appellant's Brief (filed Sept. 10, 2007) [hereinafter "App. 
Br."] and Reply Brief (filed Feb. 13, 2008) [hereinafter "Reply Br."], and the 
Examiner's Answer (mailed Dec. 13, 2007) [hereinafter "Ans."] and 
Advisory Action (mailed April 3, 2007) [hereinafter "Ad. Act."]. 
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36, and 38 as depending from rejected claims but reciting allowable subject 
matter. {See App. Br. 1-2.) No other claims are pending. We have 
jurisdiction under 35 U.S.C. § 6(b). 
We affirm-in-part. 

Appellant's invention provides an HTTP response including a first 
object content and second object content identifier to a device, such as a 
proxy agent 22 in device 16a, thereby enabling the device to prefetch the 
second content object from a remote web server 12b. 2 Prior to sending the 
HTTP response to the device, a predictive caching operation in a remote 
server identifies the second content object as relevant to the first content 
object. The invention allows the device to prefetch and cache the second 
content object prior to its having been previously downloaded to the device. 
Prior art schemes typically cached only objects previously requested and 
downloaded. (Abstract: Spec. 1:10 to 2:3, 10:5-28; Fig. 1.) 

Exemplary claim 1 follows: 

1 . A method of providing content to a device according 
to Hypertext Transport Protocol (HTTP), the method comprising: 

receiving an HTTP request for a first content object; 

identifying a content operation identifier that identifies a 
corresponding second content object determined as relevant to the first 
content object by a predictive caching operation, the content operation 
identifier including a directive for prefetching the second content object as a 
content operation distinct from presentation of the first content object by the 
device; and 

sending to the device an HTTP response to the HTTP request, the 
HTTP response including the first content object and the content operation 



2 Bey da employs the hyphenated version (i.e., "pre-fetch") while Appellants 
do not, and the Examiner employs both versions. The non-hyphenated 
version (i.e., "prefetch") is employed throughout this opinion unless the 
other version is being quoted. 
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identifier, enabling the device to perform the prefetching of the second 
content object based on receipt of the content operation identifier and 
distinct from the presentation of the first content object. 

The Examiner relies on the following prior art references: 

Schloss US 6, 249,844 Bl June 19, 2001 

Beyda US 2003/0061451 Mar. 27, 2003 

The Examiner rejected: 

Claims 1, 2, 13, 14, 20, 21, 32, and 33 under 35 U.S.C. § 102(e) based 
on Beyda; and 

Claims 3, 4, 6, 8, 9, 11, 15, 16, 18, 22, 23, 25, 27, 28, 30, 34, 35, and 
37 under 35 U.S.C. 103(a) based on Beyda and Schloss. 



ISSUES 

Appellant contests (App. Br. 10-16) the Examiner's finding that 
Beyda satisfies independent claim 1 and similar limitations in independent 
claims 13, 20, and 32. Appellant's contention raises the following issue: 
Did Appellant demonstrate that the Examiner erred in finding that Beyda 
discloses "sending to the device an HTTP response to the HTTP request, the 
HTTP response including the first content object and the content operation 
identifier, enabling the device to perform the prefetching of the second 
content object based on receipt of the content operation identifier and 
distinct from the presentation of the first content object," as set forth in 
claim 1? 

1) Appellant also contests (App. Br. 16-19) the Examiner's finding 
that Beyda and Schloss teach the limitations of the dependent claims, raising 
the following issues: Did Appellant demonstrate that the Examiner erred in 
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finding that Beyda and Schloss collectively teach an HTTP response which 
includes a content operation tag that includes a content operation identifier 
including a directive tag specifying the corresponding content operation to 
be performed by the device and an object identifier that specifies a location 
of the second content object, as required by dependent claims 3, 4, 8, 9, 15, 
16, 22, 23, 27, 28, 34, and 35; 

2) inserting into the HTTP response at least one extensible HTTP 
header that specifies the content operation identifier including a directive tag 
specifying the content operation and the object identifier, as set forth in 
claims 6, 11, 25, and 30; and 

3) a header as recited in claims 18 and 37? 

FINDINGS OF FACT (FF) 
Beyda 

1. Beyda discloses a "method for [a] predictive caching operation 
[which] determines a time-based pattern of a high-access period for a web 
page, and pre-fetches the web page into a cache before the high access 
period begins. A table is generated where the table comprises a URL 
[(Universal Resource Locator)], a time of last access and a time stamp of the 
pre-fetched web page." (f 0012.) Beyda' s cache system encompasses 
HTML pages, images and files, and HTTP protocols, (ff 0002, 0005, 0009.) 

2. Beyda' s system pre-fetches or fetches web pages and fills a local 
cache based on prior and current client requests for the web page. Each web 
page has a unique URL, and also different types of files, such as graphic, 
audio, video, and text files, referred to as objects, or elements, with each 
having a unique URL. For example, the web page www.cnn.com has three 
graphic files and an audio file with the following unique URLs: 
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www . cnn. com/graphic .jpg 1 , www . cnn. com/graphic .jpg2 ; 
www.cnn.com/graphic.jpgUsic 3], and www.cnn.com/audio. (ff 0010, 
0017.) 

3. When a client sends a new request to a local server 14 (which 
includes a proxy server 16 and cache) for a particular web page, if the 
requested URL is not found in the local server cache (previously stored there 
via a previous client request from that client or another client), the local 
server directs the new request to the remote server 18. The remote server 
then sends a response back to the client 10 via the local server, while the 
local server updates its cache with the response. 

The response includes the requested web page (including all its 
associated elements and URLs), the time of last update for the page, and the 
time stamp corresponding to the client's request. The local server/cache 
stores the URLs and both time data types in a table as depicted in Figure 2. 
(The remote server 18 updates the web page URL time stamp if any part of 
the page, including any of its graphic or audio files objects, change.) 

On the other hand, if the requested web page URL is found in the 
local server, the local server begins downloading the shell of the requested 
web page (listing the various elements/objects with different URLs and 
timestamps of creation) from the remote server 18. The shell of the page 
may have a new URL (e.g., for a new audio file) not listed in the local cache. 
If so, the local server assumes the web page has changed and downloads the 
new URL (and its element) from the remote server. Similarly, if the time 
stamps of the different URLs associated with a web page do not match the 
local cache time stamps, the local sever downloads the more recent URL and 
its element from the remote server and sends that version to the client. On 
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the other hand, if the time stamps of the shell match the time in the local 
cache, the local server sends the cached copies of the URL elements to the 
client. Beyda refers to this downloading process as "element-by-element 
downloading" (f 0028). (ff 0010, 0016-0020; Fig. 1.) 

4. Beyda' s local server 14 also prefetches the web pages described 
above from a remote server 18 that are predicted to be in high demand 
during a certain time of the week. The local server 14 predicts this demand 
by recording the hit rate of every web page previously requested by clients. 
Prefetching may occur, for example, the hour before the expected high 
demand, to ensure the most recent web pages, with their associated URLs 
and objects, are locally cached. The prefetched pages, including all web 
content and associated URLs, are then accessed in the same fashion as 
described above (FF 3) by requesting clients. In other words, URLs, the 
web shell, and time stamps are sent from the remote server and compared at 
the local server on an element-by-element basis, (ff 0021-28; see also FF 
1.) 

5. In addition to this element-by-element predictive prefetching, 
Beyda also discloses that the predictive prefetching operation can be 
performed as occurred in the prior art, by downloading the entire web page 
and its contents (i.e., downloading all the text, audio, video, and graphic files 
associated with the page at the same time), (ff 0010, 0028.) 

Appellant's Specification 

6. Appellant describes "HTML directive tags 40 as specified content 
operations" which include "HTML tag information 42 and 44." (Spec. 
10:20-23.) Tag 42a includes a command to prefetch, while tag information 
44 includes uniform resource indicators (URIs). (Spec. 7:16-20; Fig. 2A.) 



6 



Appeal 2009-005558 
Application 09/986,967 

7. Appellants describe a proxy agent 22 as "checking] for the 
existence of the content object in its cache 24 to determine if the content 
object has already been fetched or prefetched." (Spec. 10:13-15.) 

PRINCIPLES OF LAW 

"[T]he examiner bears the initial burden, on review of the prior art or 
on any other ground, of presenting a prima facie case of unpatentability." In 
re Oetiker, 977 F.2d 1443, 1445 (Fed. Cir. 1992). Appellant carries the 
burden on appeal to show reversible error by the Examiner in maintaining 
the rejection. See In re Kahn, 441 F.3d 977, 985-86 (Fed. Cir. 2006) ("On 
appeal to the Board, an applicant can overcome a rejection by showing 
insufficient evidence of prima facie obviousness or by rebutting the prima 
facie case with evidence of secondary indicia of nonobviousness." (Citation 
omitted).) 

Under § 102, anticipation is established when a single prior art 
reference discloses expressly or under the principles of inherency each and 
every limitation of the claimed invention. In re Paulsen, 30 F.3d 1475, 
1478-79 (Fed. Cir. 1994) (citation omitted). 

Under § 103, "there must be some articulated reasoning with some 
rational underpinning to support the legal conclusion of obviousness." 
Kahn, 441 F.3d at 988. "On appeal to the Board, an applicant can overcome 
a rejection by showing insufficient evidence of prima facie obviousness . . . 
." Id. at 985-986 (quoting In re Rouffet, 149 F.3d 1350, 1355 (Fed. Cir. 
1998).) 
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ANALYSIS 

Anticipation Rejection Based On Bevda 

Claims 1, 2, 13, 14, 20, 21, 32, and 33 

The sending clause of claim 1 requires "sending to the device an 

HTTP response to the HTTP request, the HTTP response including the first 

content object and the content operation identifier, enabling the device to 

perform the prefecthing of the second content object based on receipt of the 

content operation identifier and distinct form the presentation of the first 

content object" (emphasis added). 

With respect to this sending clause, Appellant appears to direct 

attention to Bey da's alleged lack of a teaching of a specific device which 

receives the HTTP response, summarizing as follows: 

Hence, although Bey da discloses a local server 14 that 
performs its own predictive prefetching based on reviewing its 
cache (illustrated in Figure 2), Beyda provides no disclosure or 
suggestion that the predictive prefetching is added within an 
HTTP response, enabling another device receiving the HTTP 
response to perform the prefetching of the second content 
object in response to receipt of the content operation identifier 
specifying the directive for prefetching. 

(App. Br. 15.) 

The Examiner responded as follows: 

Beyda discloses sending to the device an HTTP response . . . 
from remote server 18. . . including both the first content object 
[= sub-entry URLs such as either object 36, 38, 40, or 42] and 
the content operation identifier [= URL, paragraph 0017] that 
includes a directive for prefetching the second content object [= 
predictively pre-fetch web pages and their corresponding 
elements, e.g. URL . . .] as a content operation distinct from 
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presentation of the first content object by the device [= 
predictive caching operation can operate independently . . .]. 

(Ans. 9 (emphasis added).) 

Therefore, as the Examiner found that Bey da's remote server 18 sends 
the HTTP response to the device (FF 1-3), it follows that the local server 14 
constitutes the device of the claim. Bey da's local server performs 
prefetching, as Appellant's above-quoted argument notes. (Accord FF 4-5.) 

In other words, one of the URLs (of several in a web page) sent by 
Bey da's remote server 18 in response to a prior request for a web page from 
the client 10 and local server 14 (FF 2, 3) constitutes a content operation 
identifier in the sending clause of claim 1. One of these URLs also satisfies 
the same identifier recited in the identifying clause of claim 1: i.e., 
"identifying a content operation identifier that identifies a second content 
object determined as relevant to the first object by a predictive caching 
operation, the content operation identifier including a directive for 
prefetching the second content object as a content object distinct from 
presentation of the first content object by the device," as the Examiner 
found. (Ans. 8-10.) 

That is, the Examiner found that one of the secondary URLs (from the 
remote server 18) constitutes "a content operation identifier . . . [which] 
includes a directive for prefetching." (Ans. 8, 10; Ad. Act.) 3 The record 



3 The Examiner stated: "In page 7, line 19, of the specification, the 
applicant discloses a directive tag 42a specifying a prefetch operation. 
However, the claims specify that a directive for prefetching which is nothing 
more than pre-ftetching [sic] portion of a single cache e.g. its URL . . . ." 
Footnote continued on the next page. 
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supports this finding. Beyda's local server 14 employs all the URLs (in the 
web page of the HTTP response sent from the remote server) to determine 
which URLs and their objects to prefetch. 

While Beyda's local server uses additional information to determine 
which URLs to prefetch, claim 1 does not preclude this, contrary to implied 
arguments otherwise made by Appellant. (Reply Br. 10 (referring to internal 
operations of the local server 14).) These URLs, sent in the HTTP response 
from the remote server, are necessary pre-requisites that "direct" the local 
server as to which URLs and objects to later prefetch (based on the 
additional requirement of an anticipated high demand according to a pattern 
of high demand previous HTTP requests). Also, a particular web page URL, 
or an element URL (for a file in that web page), having been previously 
requested more than a certain threshold number of times as compared to 
other requested URLs, triggers that particular URL as a directive to prefetch, 
according to Beyda's prefetching scheme. (FF 4-5.) As such, each URL, or 
only one URL, of a respective web page, reasonably constitutes a directive 
according to claim 1 . 4 

While Appellant repeats the Examiner's finding quoted supra in note 
3, Appellant's response fails to squarely address whether or not a URL 
constitutes a directive. For example, Appellant responds as follows: "the 
rejection fails to present any interpretation ... of the claimed 'directive for 
prefetching': the broadest reasonable interpretation must be (1) consistent 



(Ad. Act. 2 (emphasis added).) The Examiner twice repeated this finding. 
(Ans. 8, 10.) 

4 Beyda's local server 14 can prefetch either the whole page and all its 
elements or each element, element-by-element. (FF 5.) 
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with the specification, and (2) consistent with the interpretation that those 
skilled in the art would reach." (App. Br. 15-16.) This response does not 
explain why a URL, which the Examiner thrice relied upon (supra note 3) as 
part of Appellant' s disclosed directive, fails to suffice as the claimed 
directive for prefetching. The response does not explain how the finding is 
either inconsistent with the Specification or known interpretations. 
Appellant's Specification supports the Examiner's interpretation under 
which a "directive" (40) merely includes the URL information (44). (FF 6.) 

Appellant also responds to the URL directive issue by stating that 
"[t]he specification explicitly describes prefetching as fetching new content 
without reiving on a client request to provide content acceleration." (App. 
Br. 16.) Again, this response does not address whether Bey da's URL 
constitutes the directive recited in claim 1 . While it does address 
prefetching, Appellant provides no explicit definition (or description) which 
would replace the ordinary meaning of that term as evidenced by 
Appellant's (FF 7) and Bey da's (FF 2-4) use of it. That is, Bey da (FF 2-4) 
and Appellants' Specification (FF 7) clearly demonstrate that prefetching 
does not preclude a prior request. Rather, prefetching merely involves 
caching (i.e., saving) prior requests in anticipation of further requests. (FF 2, 
4, 7.) As such, Appellant's related remark (Reply. Br. 6) that Beyda 
performs a "post fetch" is also unavailing. 

Therefore, in response to an HTTP request from a client 10 or the 
local server 14, Beyda' s remote server 18 sends a web page, and thereby 
identifies a corresponding second content object including a directive for 
prefetching (e.g., identifies the object audio file, and its URL directive for 
prefetching - www.cnn.com/audio), which is determined to be relevant to the 
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first content object (e.g., either the web page associated with the URL 
www.cnn.com, or another graphic file in the web page). (FF 2-3.) 
Therefore, Beyda satisfies the receiving and identifying steps of claim 1 . 

After the above two steps, Beyda' s remote server 18 sends, to the 
local server 14, an HTTP response including the first content object and the 
content operation identifier, which enables the local server device "to 
perform the prefetching of the second content object based on receipt of the 
content operation identifier and distinct from the presentation of the first 
content object," thereby also satisfying the "sending" step of claim 1. (FF 2- 
5.) 

Appellant also argues Examiner error with respect to "the claimed 
feature of a single HTTP response including both the first content object (for 
presentation of the first content object) and the directive for prefetching the 
second content object distinct from the presentation of the first content 
object. " (App. Br. 16.) Notwithstanding these various underlined portions, 
this argument and related arguments in the Appeal Brief and Reply Brief 
{see e.g., Reply Br. 10) do not explain in a clear fashion why Beyda does not 
disclose any of the elements mentioned. 

Moreover, and by way of example, Appellant's Brief does not specify 
any clear support for the "distinct from presentation" and "distinct from the 
presentation" elements, which appear respectively in the identifying and 
sending steps of claim 1, as indicated supra. {See App. Br. 3: 1-2 (no Spec, 
cite); 3:26-27 (citing Spec. 8:7-9).) 5 On the other hand, Appellant refers to 

5 The cited passage at page 8 of the Specification refers to preferably 
"providing] the content operation identifier distinct from the content itself 
by inserting the content operation identifiers into the HTTP header." (Spec. 
Footnote continued on the next page. 



12 



Appeal 2009-005558 
Application 09/986,967 

"the device" in claim 1 as supported by "16a or 16b of Fig. 1," which 
correspond to proxy agents, as opposed to client devices. (App. Br. 3:3.) In 
other words, Appellant's proxy agents do not "present" content according to 
any meaningful distinction over the presentation (i.e., transmission and 
processing) of data by Beyda's local proxy server 14/16. Absent a clear 
argument buttressed by support for the elusive meaning behind the clause, 
the record provides no basis for a finding of Examiner error. 6 

Thus, for example, Beyda satisfies the identifying step recitation of "a 
directive content operation distinct from presentation of the first content 
object by the device," because the URL directive (e.g., www.cnn.com/audio) 
is distinct from the presentation of the first content object (the web page for 
www.cnn.com). That is, Beyda's local server device "presents" (i.e., 
transmits) the first content object (and the URL directive for the second 
content object) to the client computer, but employs the URL content 
operation directive in a distinct operation, i.e., to facilitate prefetching. 
Under an alternative interpretation, the whole web page need not constitute 
the first content object of the claim; rather, another graphic file (e.g., 
pertaining to www.cnn.com/graphic.jpgl) satisfies that limitation. 



8:7-9.) The passage does not refer specifically or clearly to the presentation 
of data content, such as for example on a computer screen, but rather, 
appears to relate to the location of commands in a data stream - implying 
that distinct presentation embraces different data locations in a data stream. 
6 Appellant, for example, also argues, that because Beyda's local server 14 
stores elements in a cache, "the element-by-element [sic] is not a 
'presentation' of the first content object, as claimed." (Reply Br. 6.) This 
argument not only does not explain what Appellant means by presentation, 
but the argument also appears directed to an alleged lack of presentation of 
first content operation, as opposed to directed to whether the presentation is 
distinct, as argued previously. 
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Continuing the interpretation, Bey da's local server presents the URL content 
operation directive (e.g., www.cnn.com/audio) "distinct from the 
presentation" of the graphic file, because for example, both are located in 
different portions of the web page. Alternatively, one is an object, the other 
is a URL, so that any presentation thereof is "distinct." Also, one pertains to 
an audio file, another to graphics, or text, etc., thereby allowing for distinct 
presentations. 

Beyda also satisfies the "distinct" element in the sending step 
recitation of "enabling the device to perform the prefetching of the second 
content object based on receipt of the content operation identifier and 
distinct from the presentation of the first content object" for similar reasons. 
For example, Beyda' s device, the local server 14, prefetches the second 
content object, the file pertaining to www.cnn.com/audio, from the remote 
server, which is distinct from how Beyda' s device presents (i.e., transmits) 
the web page (or another graphic file) to the client. Also, the graphic and 
audio files are located in different portions of the data stream (or web page), 
assuming for the sake of argument, that the clause requires both items to be 
presented in a distinct manner. Moreover, the clause "and distinct from 
presentation" does not necessarily require the local server to perform any 
presentation, but ambiguously leaves open the possibility that another 
device, such as the client computer, performs the presentation. Of course, 
under that circumstance, an audio file and graphics file are by nature 
presented differently. 

Appellant' s remaining arguments throughout both briefs have been 
carefully considered. The arguments appear similar to those addressed 
above, often with different portions underlined or otherwise emphasized, but 
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without clear explanation as to why Beyda does not meet the recited 
limitations of claim 1. "The problem in this case is that the appellants failed 
to make their intended meaning explicitly clear." In re Morris, 127 F.3d 
1048, 1056 (Fed. Cir. 1997). "It is the applicants' burden to precisely define 
the invention, not the PTO's." Id. (citation omitted). 

For the remaining independent claims, Appellant relies on the 
arguments presented for claim 1, and summarizes as follows: Beyda does 
not disclose "the HTTP response, that includes both the first content object 
and the directive for prefetching," which "is sent to the device in claim 1, 
received from the destination server in claims 13 and 32, and output by the 
interface of the server of claim 20." (App. Br. 16 (emphasis omitted.).) For 
reasons similar to those involved above with respect to claim 1, Beyda' s 
remote server 18 constitutes the destination servers recited in claims 13 and 
32, and includes the interface of the server recited in claim 20. 

Appellant presents no separate patentability argument for claims 2, 
14, 21, and 33, which respectively depend from claims 1,13, 20, and 32. 
Based on the foregoing discussion, Appellant has not demonstrated 
Examiner error in the rejection based on Beyda of claims 1,2, 13, 14, 20, 21, 
32, and 33. 

Obviousness Rejection Based On Beyda and Schloss 
Claims 3, 4, 8, 9, 15, 16, 22, 23, 27, 28, 34, and 35 
Appellant asserts that the Examiner erred in combining Schloss with 
Beyda to arrive at these claims, because Schloss refers to replacing an object 
with a tag. (App. Br. 16-19.) The Examiner apparently employed Schloss to 
include a teaching of adding a directive tag specifying the corresponding 
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operation to be performed and an object identifier. (The Examiner's 

rejection is interpreted as requiring Schloss, in part, because the URL in 

Beyda does not, by itself, specify the operation. {See Ans. 5).) The 

Examiner responded to Appellant' s argument by stating that replacing 

includes adding. (Ans. 10-12.) In other words, the Examiner apparently 

reasons that the claims do not preclude subtracting the existing first object of 

Beyda and adding the tag elements of Schloss. 

In reply to the Examiner's replacement rationale, Appellant states that 

the hypothetical combination simply would teach: 

replacing uncacheable objects with identifiers . Consequently, 
the hypothetical combination would remove the first content 
object and replace the first content object with a persistent 
object fragment identifier. Hence, the hypothetical combination 
would provide an HTTP response that does not include the first 
content object, but instead includes the persistent object 
fragment identifier in place of the first content object. 

(Reply Br. 12.) 

As Appellant's argument indicates, these claims require both a 
directive specifying tag and the first object content in the HTTP response. 
Based on the arguments and evidence presented, Appellant's argument 
demonstrates that the hypothetical combination removes the first content 
object. Accordingly, Appellant's argument demonstrates error in the 
rejection of these claims. 

Claims 6, 11, 25, and 30 
Appellant's argument (App. Br. 18-19) with respect to claims "7 [sic: 
6], 11, 25, and 30," 7 asserts that "the rejection fails to provide any analysis 



7 Claim 7 does not stand rejected and is not on appeal. 
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of any 'apparent reason'" (id. at 18 (n. 5 citing KSR, cite omitted here)) as 
sufficient to arrive at the recited "inserting into the HTTP response at least 
one extensible HTTP header . . . ." Appellant is correct, the Examiner failed 
to separately address similar claims 6, 11, 25, and 30, or otherwise discuss 
the extensible header limitation recited therein in the Final Rejection or the 
Answer. "[T]here must be some articulated reasoning with some rational 
underpinning to support the legal conclusion of obviousness." Kahn, 441 
F.3d at 988. "On appeal to the Board, an applicant can overcome a rejection 
by showing insufficient evidence of prima facie obviousness . . . ." Id. at 
985-986 (quoting Roujfet, 149 F.3d at 1355). Accordingly, Appellant has 
shown error in the rejection of claims 6, 11, 25, and 30. 

Claims 18 and 37 

Appellant argues that the combination of Beyda and Schloss does not 
satisfy these claims. (App. Br. 17, 18.) These claims require a header which 
includes the content operation identifier specified therein. It appears, 
although it is not clear from the rejection, that the Examiner may have used 
Schloss to satisfy at least the header limitation. 

Based on the foregoing discussion and Appellant's arguments, 
Schloss' s teachings would result in replacing the first content object of 
Beyda, thereby resulting in "no disclosure or suggestion of the claimed 
features as a whole." (App. Br. 17.) Therefore, the Examiner's rejection 
does not include a sufficient factual foundation to support the rejection of 
claims 18 and 37. 

CONCLUSION 

Appellant did not demonstrate that the Examiner erred in finding that 
Beyda discloses "sending to the device an HTTP response to the HTTP 
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request, the HTTP response including the first content object and the content 
operation identifier, enabling the device to perform the prefetching of the 
second content object based on receipt of the content operation identifier and 
distinct from the presentation of the first content object," as set forth in 
claim 1. 

Appellant did demonstrate that the Examiner erred in finding that 
Beyda and Schloss collectively teach the limitations set forth in dependent 
claims 3, 4, 6, 8, 9, 11, 15, 16, 18, 22, 23, 25, 27, 28, 30, 34, 35, and 37. 

DECISION 

We affirm the Examiner's decision rejecting claims 1,2, 13, 14, 20, 
21, 32, and 33. 

We reverse the Examiner's decision rejecting claims 3, 4, 6, 8, 9, 11, 
15, 16, 18, 22, 23, 25, 27, 28, 30, 34, 35, and 37. 

No time period for taking any subsequent action in connection with 
this appeal may be extended under 37 C.F.R. § 1.136. See 37 C.F.R. 
§ 1.136(a)(l)(iv). 

AFFIRMED-IN-PART 



rvb 

Leon R. Turkevich 
2000 M Street, NW 
7 th Floor 

Washington, DC 20036-3307 
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